マシン名のフォーマット¶

NFS クライアントはいろいろな方法で指定できる。

single host

これはもっとも普通のフォーマットである。ホストの指定には、 レゾルバが認識できる省略形、FQDN、IP アドレスのどれを用いてもよい。

netgroups

NIS のネットグループを @group のように与えることができる。ネットグループのすべてのメンバーのうち、 ホストの部分だけが取り出され、アクセスリストに追加される。 ホストの部分が空だったり、単一のダッシュ (-) だったものは無視される。

ワイルドカード

マシン名の指定には、ワイルドカード文字として * と ? を用いることができる。 これらを使うと exports ファイルをコンパクトにできる。 例えば *.cs.foo.edu はドメイン cs.foo.edu にある すべてのホストにマッチする。 ただし、これらのワイルドカード文字はドメイン名のドット (.) にはマッチしない。 したがって上記のパターンは、ドメイン内の a.b.cs.foo.edu のようなホストにはマッチしない。

IP networks

ディレクトリを IP の (サブ) ネットワークに存在するすべてのホストに 同時にエクスポートすることもできる。 これには IP アドレスとネットマスクのペアを address/netmask のように指定すればよい。

=public

これは特殊な意味を持つ「ホスト名」で、その前に与えられたディレクトリ が public root ディレクトリであることを示す (WebNFS と public root ハンドルの詳細に関しては nfsd(8) の WebNFS のセクションを参照のこと)。 この書式を用いる際には、 =public がその行での唯一のホスト名エントリでなければならない。 またエクスポートオプションを指定してはならない。 この指定によって、 ディレクトリが実際にエクスポートされるわけではないことに注意すること。 エクスポートオプションは、これとは別のエントリで指定する必要がある。

public root パスは nfsd を --public-root オプションを指定して起動することによっても指定できる。 public root の複数指定は無視される。

一般的なオプション¶

mountd と nfsd は以下のエクスポートオプションを受け付ける。

secure

このオプションを指定すると、IPPORT_RESERVED (1024) より小さな internet ポートから発したリクエストしか受けつけない。 このオプションはデフォルトで有効になっている。 無効にするには insecure と指定する。

rw

クライアントによるファイルとディレクトリの変更を許可する。 デフォルトでは、クライアントは読み込みのリクエストだけに制限されている。 (これは ro オプションで明示した場合も同じ)。

noaccess

このオプションを付けたクライアントは、 そのディレクトリ以下のすべてのファイルに対してアクセスできなくなる。 あるディレクトリ階層をクライアントにエクスポートするとき、 特定のサブディレクトリを除きたい場合などに便利である。 noaccess フラグが付いたディレクトリのクライアントからの見え方は、 非常に制限されたものとなる。 ディレクトリ属性と、`.' および `..' の閲覧だけが許される。 readdir に対して返されるエントリもこの 2 つだけになる。

link_relative

絶対パス形式のシンボリックリンクを相対パス形式のリンクに変換する (絶対パス形式とは、リンクの内容が "/" で始まるものである)。 変換は次のように行われる。 まずリンクが置かれているディレクトリの、サーバのルートからの 深さを取得する。そしてその数だけ '../' を絶対リンクの前に付加する。 マウントポイントのルートからの位置が異なる場合、 この変換には微妙な (おそらく障害の原因となる) あいまいさが含まれる可能性がある。

link_absolute

全てのシンボリックリンクをそのままにする。これがデフォルトである。

ユーザ ID のマッピング¶

サーバマシン上のファイルに対する nfsd によるアクセスコントロールは、 それぞれの NFS RPC request の際に与えられる uid と gid に基づいている。 ユーザは通常、サーバ上にある自分のファイルには、 それが普通のファイルシステム上にあるのと同様に アクセス可能であることを期待している。 これにはクライアントとサーバ上で用いられる uid と gid がそれぞれ同じである必要があるが、 これは常に真であるとは限らず、望ましいとも限らない。

クライアントマシンの root が NFS サーバのファイルにアクセスするとき、 サーバの root として扱われてしまうのは、ほとんどの場合は望ましくない。 このため uid 0 は普通は別の id (anonymous や nobody uid) にマッピングされる。 この動作は `root squashing' と呼ばれるが、これがデフォルトである。 no_root_squash を使えばオフにできる。

デフォルトでは、 nfsd は起動時に password ファイル中の nobody ユーザを参照して、 anonymous の uid と gid を得ようとする。 もしそれが見つからない場合には、 uid と gid として -2 (つまり 65534) を用いる。 これらの数値は anonuid と anongid オプションによって変更できる。

これに加え、 nfsd によって nobody に割り当てるべき適当な uid と gid とを指定することもできる。 最後に、 all_squash オプションを指定すれば、 全ての user request を anonymous uid に割り当てることもできる。

マシンごとに uid が異なるような場合への導入を容易にするため、 nfsd ではサーバの uid をクライアントの uid に (あるいはその逆に) 動的にマッピングする手法をいくつか提供している。 静的なマッピングファイル、NIS ベースのマッピング、 ugidd ベースのマッピング、である。

ugidd ベースのマッピングは map_daemon オプションを指定して UGID RPC プロトコルを使えば可能となる。 このプロトコルを動かすにはクライアントで ugidd(8) mapping デーモンを動作させる必要がある。 これは 3 つある方法の中で、セキュリティ的には最悪である。 なぜなら ugidd を動作させると、誰でもクライアントに問い合わせて、 有効なユーザ名のリストを入手できてしまうからである。 ugidd へのアクセスを特定のホストのみに制限して、身を守ることもできる。 これには許可するホストのリストを hosts.allow または hosts.deny ファイルに記述すればよい。サービス名は ugidd である。これらのファイルの文法については、 hosts_access(5) を参照してほしい。

静的なマッピングは map_static オプションによって動作させることができる。 このオプションは、マッピングを記述したファイルの名前を引数にとる。 NIS ベースのマッピングは、クライアントの NIS サーバに問い合わせて、 サーバーホストでのユーザ名およびグループ名から クライアントでのユーザ名およびグループ名への、 マッピング情報を入手する。

以下にマッピングオプションの完全なリストをあげる:

root_squash

uid/gid が 0 のリクエストを annonymous uid/gid にマッピングする。 このオプションは、root 以外の uid には適用されない。 他にも注意すべき uid は存在する (例えば bin など) ので、注意する必要がある。

no_root_squash

root squashing を無効にする。 このオプションは主にディスクレスクライアントにとって便利である。

squash_uids and squash_gids

このオプションは、annonymous にマッピングされる uid や gid のリストを明示するためのものである。 id のリストとしては以下のような指定が有効である:

squash_uids=0-15,20,25-50

通常の squash リストはもっとずっと簡単なものになるだろうが。

all_squash

全ての uid とgid を anonymous にマッピングする。 これは NFS エクスポートされた公開 FTP ディレクトリや、 news のスプールディレクトリ等に便利である。 これと逆のオプションは no_all_squash であり、こちらがデフォルトになっている。

map_daemon

このオプションは 動的な uid/gid のマッピングを有効にする。 NFS request 中のそれぞれの uid はサーバ上の対応する uid に変換され、 NFS reply 中の uid はそれぞれ逆に変換される。 このオプションを用いるには、クライアントホストで rpc.ugidd(8) が動作していることが必要である。 デフォルトでは、全ての uid を変えない map_identity となっている。 普通の squash オプションは、 動的なマッピングか否かを気にすることなく適用できる。

map_static

このオプションを指定すると静的なマッピングが可能となる。 uid/gid マッピングが記述されたファイル名を以下のように指定する。

map_static=/etc/nfs/foobar.map

ファイルのフォーマットは以下のようなものである。

# Mapping for client foobar:
#    remote     local
uid  0-99       -       # squash these
uid  100-500    1000    # map 100-500 to 1000-1400
gid  0-49       -       # squash these
gid  50-100     700     # map 50-100 to 700-750

map_nis

このオプションを指定すると NIS ベースの uid/gid マッピングが可能となる。 例えば、サーバが uid 123 の指定を受けると、 サーバはまずその uid に対応するローカルのログイン名を調べる。 次に NFS クライアントの NIS サーバに接続して、 そのログイン名に対応する uid を取得する。

これを行うには、NFS サーバがクライアントの NIS ドメインを 知っていなければならない。 このドメインは map_nis オプションの引数として以下のように指定する。

map_nis=foo.com

ただここに NIS ドメインを記述するだけでは、通常は充分ではない。 nfsd が NIS サーバにコンタクトできるようにするには、 他の作業が必要となるだろう。 利用しているディストリビューションが NYS ライブラリを使っている場合は、 クライアントのドメインのサーバを /etc/yp.conf に一つ以上指定する必要があるだろう。 他の NIS ライブラリを用いている場合には、 yp.conf によって設定できるような、特殊な ypbind(8) を入手する必要があるかもしれない。

anonuid および anongid

これらのオプションは anonymous アカウントの uid と gid を明示的にセットする。 これは、全てのリクエストが一人のユーザからになるような PC/NFS clients にとって主に有効である。 例えば、以下の「例」のセクションでの /home/joe というエクスポートエントリを見てほしい。 この例では、(joe からのものであると思われる) 全てのリクエストが uid 150 にマッピングされる。